A problem with Internet Protocol (IP) over wireless links when used for functions such as interactive voice conversations or video, for example, is the large header overhead. Audio and video data for IP telephony is typically carried using Real-time Transport Protocol (RTP). A packet will then, in addition to link layer framing, have an IP header (20 octets for IPv4), a User Datagram Protocol (UDP) header (8 octets), and an RTP header (12 octets) for a total of 40 octets. With IPv6, the IP header is 40 octets for a total of 60 octets. The size of the payload of the packet depends on the speech coding and frame sizes being used and may be as low as 15-20 octets.
Robust Header Compression (ROHC) offers a way to compress header information for more efficient transmission of data. (See Network Working Group, Request for Comments 3095.) Compression can be achieved, for example, by recognizing that some header fields have well known values a priori and do not have to be sent at all; and some header fields are constant throughout the lifetime of a packet stream and need only be sent once at the beginning of a packet stream. In ROHC, relevant information from past packets is maintained in a context. The context information is used to compress and decompress subsequent packets. An Initialization and Refresh (IR) packet provides a full uncompressed context of the data that is being transmitted.
The compressor and decompressor update their contexts upon the occurrence of certain events. Impairment events may lead to inconsistencies between the contexts of the compressor and decompressor, which inconsistencies may cause incorrect decompression. In a typical streaming environment, packets are received sequentially. Any packet loss could potentially degrade service until a new context rich packet, such as an IR packet, is received by the decompressor.
Under a burst model of operation, the same principles apply. In burst operation, however, because data is sent out in bursts, the receiver has access to a period of time of data. Although burst operation may offer bandwidth utilization efficiencies, it is not error free. If during the transmission of a burst there are losses, the receiver can potentially throw out an entire burst containing multiple packets thereby, degrading the quality of service, often more so than in a streaming mode of operation.
Burst operation is used in a variety of systems, including digital broadcast systems such as systems based on the Advanced Television Systems Committee Mobile/Handheld (ATSC-M/H) standard, among others. In such systems, data for multiple services are multiplexed on a given physical channel in bursts of data. As such, a receiver will receive the data for a selected service in periodic bursts rather than as a steady stream. This results in the receiver suddenly having a burst of data available to it and then having to wait for the next burst of data. Each burst may represent, for example, a second's worth of streaming audio and/or video content.
The services offered to the receiver, however, such as video and audio over RTP, may be over mechanisms that are modeled on the concept of a steady stream of data. Using the streaming model, packets are received sequentially in time. Before receiving a later packet, the receiver receives all of the packets between the current packet and the later packet. This conceptually differs from the burst model, in which the receiver at one instance receives a full set of packets representing some time period.